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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

6,801,536 Foster etal. 10-2004 

5,801 ,781 Hiroshima et al. 9-1 998 

5,732,324 Rieger, III 03-1998 
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5,815,671 



Morrison 



9-1998 



US 2003/0212996 A1 



Wolzien 



11-2003 



(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
Claims 1,4-5, 9, 17 and 18 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Foster et al (6,801,536) in view of Hiroshima et al. (US 5801781). 

Regarding Claim 1, Foster shows a receiver in a digital broadcast system 
comprising a memory device for storing content transmitted in a broadcast signal (fig. 1 
item 150, col. 4 lines 10-20, HDDI, the content comprising data files, each file being 
partitioned into segments that are in the broadcast signal (col. 3 lines 4-15, col. 4 lines 
60-67, col. 5 lines 43-67, packets), the signal being provided with at least one header 
comprising information indicating the number of segments that constitute one of the 
files, and information identifying the segments (col. 5, lines 40-67, col. 6 lines 38-64, 
type of data and block size). Foster further shows a reception device for receiving the 
transmitted broadcast signal and processing the signal to obtain the content including 
segments corresponding to the data files (see fig. 1), and a processing device 
connected to the memory device and reception device and being programmable to use 
at least one header in the transmitted broadcast signal to determine the size of (to 
allocate) at least one section in the memory for storing the data file (fig. 1, host 
processor and memory controller, col. 6 lines 50-65; col. 9, lines 1-15, FAT on storage 
medium), storing the segments of the data file in the allocated section (fig. 1, host 
processor and memory controller, col. 6 lines 50-65, col. 9 lines 1-15, FAT on storage 
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medium) and to monitor the progress of the allocated section (col. 7 lines-1-471 using 
interrupts and time stamps to fill buffers that send data to the HDD). 

Foster further discloses the a buffer size of 512 bytes of audio and video is 
defined by the MPEG-2 standard; however, the size of the buffers are essentially 
arbitrary and the particular sizes discussed and illustrated should be regarded as 
exemplary (Col. 5, lines 32-42). As such, Foster does not clearly disclose the use of the 
header comprising data to indicate how much of the memory device need to be 
allocated to store the data file. 

Hiroshima discloses the use of the packet header data to indicate how much of 
the memory device need to be allocated to store the data file (see Fig. 6, el. 122; Col. 8, 
lines 32-45) for the purpose of preventing data loss by allocating corresponding memory 
size as needed. Therefore, it would have been obvious to one of ordinary skill in the art 
at the time the invention was made to modify Foster with Hiroshima for having a buffer 
size with a packet header so to guarantee neither overflow nor underflow of the buffers. 

Regarding Claim 4, as discussed Foster shows that each segment has a header 
that identifies the total number of segments (col. 7 lines 12-18, unitary header provided 
for the total data block size) and an identification code (STC) (col. 8 lines 60-67, col. 9 
lines 1-13, using look up table to identify the STC in storage location for playback). The 
STC code in the header indicates the order in the file (col. 7 lines 5-35, col. 9 lines 1-23, 
STC in header). 

Regarding Claim 5, Foster (col. 3 lines 5-15, col. 4 lines 38-55, col. 5 lines 40-67, 
col. 6 lines 38-64, col. 7 lines 12-18, type of data and block size, unitary header 
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provides for the block size) shows that the header indicates the size of the data that 
needs to be stored. Furthermore, a block size buffer, that uses the total block size, is 
used to 51 1 the memory (col. 7 lines 1-18, block size buffer and total data block size in 
header). 

Regarding Claim 9, Foster further shows that the header file contains 
identification codes for the segments that indicate the order the segments are to appear 
in playback (Col. 8 lines 21-67; Col. 9, lines 1-23, STC used for synchronization of 
playback), and the ability to determine if the segments have been stored (col. 8 lines 15- 
35, using a buffer that continually adds data until %1 1, then stores the data together, 
effectively determining .if and when data Should be stored). 

Regarding Claim 12, Foster shows storage for storing a first portion of complete 
data files (col. 4 lines 10-25, HDD) and storage for second portions that are being 
received, or a buffer (col. 6 lines 38-65, col. 3 lines 1-15, storing data in buffer prior to 
storage on hard disk). 

Regarding Claim 17, as analyzed with respect to claim 1 , Foster further shows a 
method of implementing a file transfer from a broadcaster to a receiver in a digital 
system comprising receiving a broadcast signal having content comprising data files, 
each file being partitioned into segments that are in the broadcast signal (col. 3 lines 4- 
15, col. 4 lines 60-67, col. 5 lines 43-67, packets), the signal being provided with at least 
one header comprising information indicating information identifying the segments (col. 
5 lines 40-67, col. 6 lines 38-64, type of data and block size). Foster further shows that 
after the buffer is full, the data is selected for storing on the hard disk (col. 7 lines 1-18, 
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fixed size total data block is stored), storing the segments of the data file in the allocated 
section (fig. 1, host processor and memory controller, col. 6 lines 50-65, col. 9 lines 1- 
15, FAT on storage medium), allocating at least one section in the memory for storing 
the data file (fig. 1, host processor and memory controller, col. 6 lines 50-65, col. 9 lines 
1-15, FAT on storage medium), analyzing the information in the header to identify 
segments (col. 5 lines 44-67, analyzing header), and storing segments in the portion of 
the memory corresponding to the file (col. 6 lines 38-65, storing data according to STC 
so data will be stored in correct sequence). 

Regarding Claim 18, Foster in view of Hiroshima shows monitoring what data 
files have not been received and stored and stores them accordingly ability to determine 
if the segments have been stored (Foster; Col. 8 lines 15-35, using a buffer that 
continually adds data until full, then stores the data together, effectively determining if 
and when data should be stored). By using this buffer, Foster is able to ensure data is 
fully received before storing the data onto the storage device. 

Claims 2, 10, and 19 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Foster et al (6,80.1,536) in view of Hiroshima et al. (US 5801781) and further view 
of Rieger, III (5,732,324). 

Regarding Claim 2, Foster in view of Hiroshima shows an output device 
connected to the processing device (fig. 1 item 190). Foster in view of Hiroshima fails to 
show generating an alert message when the segments of the data file have been stored 
in memory. 
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Rieger shows alerting the user on an output device when data segments have 
been stored in memory (col. 5 lines 40-51). It would have been obvious to one of 
ordinary skill in the art at the time the invention was made to modify Foster in view of 
Hiroshima with the alert message, as taught by Rieger, so a user would be aware when 
data had been downloaded to the receiver. 

Regarding Claim 10, Foster in view of Hiroshima fails to show that the segments 
are rebroadcast and the system determines what data has been stored, subsequently 
discarding repeated data and saving new data. 

Rieger shows that the segments are rebroadcast and the system determines 
what data has been stored; subsequently discarding repeated data and saving new data 
(col. 4 lines 25-43, 55-65, using identification information to determine repeated signals 
and preventing storage). It would have been obvious to one of ordinary skill in the art at 
the time the invention was made to modify Foster in view of Hiroshima with the ability to 
ignore repeated signals, as taught by Rieger, so that the user would not store more then 
one copy of the data. 

Regarding Claim 19, Foster in view of Hiroshima does not clearly to show that 
the segments are rebroadcast and the system determines what data has been stored, 
subsequently discarding repeated data and saving new data. 

Rieger shows that the segments are rebroadcast and the system determines 
what data has been stored; subsequently discarding repeated data and saving new data 
(col. 4 lines 25-43, 55-65, using identification information to determine repeated signals 
and preventing storage). It would have been obvious to one of ordinary skill in the art at 
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the time the invention was made to modify Foster in view of Hiroshima with the ability to 
ignore repeated signals, as taught by Rieger, so that the user would not store more then 
one copy of the data. 

Claims 6-7 and 20-21 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Foster et al (6,801 ,536) in view of Hiroshima et al. (US 5801781) and further in 
view of Morrison (5,815,671). 

Regarding Claim 6, Foster in view of Hiroshima fails to show a data field 
comprising an expiration data for the data file. 

r 1 

Morrison shows message data codes that determine different aspects of the sent 
data (col. 6 lines 14-67, col. 7 lines 1-65). Included in this data is time period data, 
which controls the receiving system to stop displaying certain data after a certain time 
period, effectively expiring the data (col. 7, lines 49-65, time period). It would have been 
obvious to one of ordinary skill in the art at the time the invention was made to modify 
Foster in view of Hiroshima with the ability to include auxiliary data that could express 
expiration time, as taught by Morrison, so the system would have more parameters to 
further control the display of data. 

Regarding Claim 7, Foster in view of Hiroshima fails to show a message 
identification code. 

Morrison shows that each message is assigned a message identification code to 
indicate which of a plurality of receivers are to receive the message (col. 6 lines 14-67, 
col. 7 lines 1-65) and the processing device being able to store a message with a 
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certain code and discard other messages with different codes (col. 7 lines 15-46, using 
certain data and discarding others based on user preferences). It would have been 
obvious to one of ordinary skill in the art at the time the invention was made to modify 
Foster in view of Hiroshima with the ability to include message code data that could 
express more detailed data about a broadcast, as taught by Morrison, so the system 
would have more parameters to further control the display of data. 

Regarding Claim 20, Foster in view of Hiroshima fails to show a rebroadcast 
schedule. 

Morrison shows that rebroadcasts of data files are scheduled throughout a day 
(coi. 6 lines 14-40). Furthermore, Morrison shows that the system operates the receiver 
to automatically tune to the rebroadcast signal, extracts elements which have not been 
stored, and storing these segments (col. 6 lines 14-40). Morrison shows a system that 
re-broadcasts data several times a day. If the system has not stored a rebroadcast file, 
this gives the receiver the opportunity to store the file. Furthermore, although not 
specifically stated, it is nonetheless inherent that a storage device, upon receiving any 
data, is always a "percentage full". It would have been obvious to one of ordinary skill in 
the art at the time the invention was made to modify Foster in view of Hiroshima with the 
ability to rebroadcast and store certain files, as taught by Morrison, so that the system 
would ensure the receiver downloaded necessary tiles. 

Regarding Claim 21, Foster in view of Hiroshima fails to show a message 
identification code. Morrison shows that each message is assigned a message 
identification code to indicate which of a plurality of receivers are to receive the 
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message (col. 6 lines 14-67, col. 7 lines 1-65) and the processing device being able to 
store a message with a certain code and discard other messages with different codes 
(col. 7 lines 15-46, using certain data and discarding others based on user preferences). 
It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify Foster in view of Hiroshima with the ability to include message 
code data that could express more detailed data about a broadcast as in Morrison so 
the system would have more parameters to further control the display of data. 

Claim 8 is rejected under 35 U.S.C. 103(a) as being unpatentable over Foster et 
al (6,801,536) in view of Hiroshima et al. (US 580.1781) and further in view of Morrison 
(5,815,671) and further in view of Wolzien (2003/0212996). 

Regarding Claim 8, Foster in view of Hiroshima and Morrison fails to show that 
the code can correspond to a model of a car. 

Wolzien shows code identification information that identifies a type of car the 
user is driving (page 7-8 section 58). It would have been obvious to one of ordinary skill 
in the art at the time the invention was made to modify Foster in view of Hiroshima and 
Morrison with the ability to use car type data as in Wolzien so that information about a 
particular vehicle could be relayed to the user. 

Claim 1 1 is rejected under 35 U.S.C. 103(a) as being unpatentable over Foster et 
al. (6,801 ,536) in view of Hiroshima et al. (US 5801781) and further view of Rieger, III 
(5,732,324) and further in view of Morrison (5,81 5,671). 
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Regarding Claim 1 1 , Foster in view of Hiroshima and Rieger fails to show 
automatically operating the receiver at a selected time of day to receive and store 
segments that have not been stored yet. 

Morrison shows automatically operating the receiver at a selected time of day to 
receive and store segments that have not been stored yet (col. 6 lines 25-42, transmitted 
at a number of convenient times throughout 24 hour day, as well as repeated 
transmission). It would have been obvious to one of ordinary skill in the art at the time 
the invention was made to modify Foster in view of Hiroshima and Rieger with the ability 
to repeatedly send data at different times as in Morrison so that the user was ensured 
the data was received and that the receiving would not interrupt operation of regular 
playback. 

Claims 13-15 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Foster etal (6,801,536) in view of Morrison (5,815,671). 

Regarding Claim 13, Foster shows a method of transmitting content files 
comprising partitioning the files into segments (fig. 2 data blocks), assigning the data 
files with identification codes for the segments that indicate the order the segments are 
to appear in playback (col. 8 lines 21-67, col. 9 lines 1-23, STC used for synchronization 
of playback, using look up table to determine the STC of data in memory), including the 
segments in the broadcast signal (col. 3 lines 4-15, col. 4 lines.60-67, col. 5 lines 43-67, 
packets), and providing each segment with a header that identifies the total number of 
segments and an identification code (STC). The STC code in the header indicates the 
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order in the file (col. 7 lines 5-35, col. 9 lines 1-23, STC in header, using look up table to 
determine the STC of data in memory). 

Foster fails to show a message identification code. 

Morrison shows that each message is assigned a message identification code to 
indicate which of a plurality of receivers are to receive the message (col. 6 lines 14-67, 
col. 7 lines 1-65) and the processing device being able to store a message with a 
certain code and discard other messages with different codes (col. 7 lines 15-46, using 
certain data and discarding others based on user preferences). It would have been 
obvious to one of ordinary skill in the art at the time the invention was made to modify 
Foster with the ability to include message code data that could express more detailed 
data about a broadcast as in Morrison so the system would have more parameters to 
further control the display of data. 

Regarding Claim 14, Morrison further shows re-broadcasting data segments 
(col. 6 lines 25-40, repeated transmission). 

Regarding Claim 15, Morrison shows message data codes that determine 
different aspects of the sent data (col. 6 lines 14-67, col. 7 lines 1-65). Included in this 
data is time period data, which controls the receiving system to stop displaying certain 
data after a certain time period, effectively expiring the data (col. 7 lines 49-65, time 
period). 
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Claim 16 is rejected under 35 U.S.C. 103(a) as being unpatentable over Foster et 
al. (6,801,536) in view of Morrison (5,815,67.1) and further in view of Wolzien 
(2003/0212996). 

Regarding Claim 16, Foster in view of Morrison fails to show that the code can 
correspond to a model of a car. 

Wolzien shows code identification information that identifies a type of car the 
user is driving (page 7-8 section 58). It would have been obvious to one of ordinary skill 
in the art at the time the invention was made to modify Foster in view of Morrison with 
the ability to use car type data as in Wolzien so that information about a particular 
vehicle could be relayed to the user. 

(10) Response to Argument 

Appellant argues, "the subblocks described in Foster are generated at the set-top 
box and therefore after transmission" on Page 8 of the Appeal Brief. 

In response, the Examiner respectfully disagrees with Appellant. Appellant 
clearly misconstrues Foster's reference. Appellant self-admitted the set-top box receives 
the transport stream 210. 

In accordance with the MPEG-2 Systems Standard (ISO/IEC 13818-1), one or 
more programs are combined into a single transport stream for transmission. Data from 
each elementary stream are multiplexed together with information that allows 
synchronized presentation of the elementary streams within a program. Generally, a 
transport stream consists of one or more programs, and the audio and video elementary 
streams consist of access units. As known to those familiar with the MPEG-2 Systems 



Application/Control Number: 09/695,228 Page 14 

Art Unit: 2623 

Standard (ISO/IEC 13818-1), a program is a collection of elementary streams with a 
common time base. In other words, a program consists of all the elementary streams 
which refer to a common Program Clock Reference (PCR) clock. The elementary 
stream data is carried in Packetized Elementary Stream (PES) packets, where a PES 
packet consists of a PES packet header followed by packet data. The PES packets are 
inserted into transport stream packets for transmission. The PES packet header may 
contain decoding and presentation time stamps (DTS and PTS) as well as other 
optional fields. Transport stream packets, on the other hand, begin with a 4 bytes prefix 
containing the 13-bit packet ID (PID). The PID identifies, via four Program Specific 
Information (PSI) tables, the contents of the data contained in the transport stream 
packet payload. 

In view of that one of ordinary skill in the art would understand that the transport 
stream 210 is encoded at the headend before it could be transmitted to the set-top box 
and further understand that Foster (Fig. 3, el. 310 and 340) does NOT build sub-blocks 
at the receiver, as alleged by Appellant but rather Foster's transport demux (Fig. 2, el. 
220) recovers the audio PES packets data, video PES packets data from the Transport 
stream 210 according to MPEG-2 Standard, as disclosed (Col. 5, lines 55-Col. 6. lines 
50). As such, Appellant is wrong. 

Appellant further argues, "neither the packets in the transport stream 210 nor the 
sub-blocks in Foster et al. indicate the number of segments that constitute a partitioned 
file nor identify each segment" on Page 10 of the Appeal Brief. 
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In response, the Examiner respectfully again disagrees with Appellant because, 
according to MPEG-2 standard, the MPEG header is an identifier of each packet in 
which each packet is a file and bytes within the packet are segments. 

Appellant further argues, "The Office Action apparently analogizes packets in a 
transport stream 210 of Foster et al. to be data files as claimed and bytes in those 
packets to be segments as claimed. This is incorrect since the bytes of packet are not 
interspersed in the transport stream of Foster et al. in contrast to segments of the data 
file recited in claim 1 being interspersed in a broadcast signal" on Page 9 of the Appeal 
Brief. 

In response, the Examiner respectfully disagrees with Appellant because 
Appellant again and again misconstrues Foster reference. First of all Appellant's claim 
limitations do not specifically describe/claim what constitutes a file or a segment. 
Secondly, Appellant's claim limitations do not specifically describe/claim how the 
segments are interspersed in the broadcast signal. Secondly, limitation in Claim 1 
requires, "...the content comprising data files, said data files each being partitioned into 
segments that are interspersed in the broadcast signal, ..." 

As such, the transport stream (210) comprises at least a video program and is 
encoded, according to MPEG-2 standard, into packets (notes, the content of transport 
stream comprises packets or data files). Foster further shows the video and audio 
packets are interspersed in the broadcast signal (see Foster Fig. 2, wherein transport 
stream (210) with packets of video and audio (212) are interspersed in the transport 
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stream (210) of the broadcast signal); as such, Bytes of video and audio packets are 
also interspersed in the broadcast signal. 

Appellant further argues "The headers of the transport stream packets of Foster 
et al. merely identify the type of data (i.e., audio or video) in the packets, but do not 
relate the packets to others that constitute a data file, unlike the claimed segments and 
header" on Page 1 1 of the Appeal Brief. 

In response, the Examiner respectfully again disagrees with Appellant because, 
according to MPEG-2 standard, the MPEG header is an identifier of each packet. 

Appellant further argues, "The PESs, however, are created at the STB" on Page 
1 1 of the Appeal Brief. 

In response, the Examiner respectfully disagrees with Appellant for the obvious 
reasons, as discussed above, in which PES is created at the Headend and NOT at the 
STB, as alleged by Appellant. The STB's transport demux (Fig. 2, el. 220) recovers the 
audio PES packets data, video PES packets data from the Transport stream 210 
according to MPEG-2 Standard, as disclosed (Col. 5, lines 55-Col. 6. lines 50). As such, 
Appellant is wrong. 

Furthermore, Appellant argues that Hiroshima does not disclose a header 
comprising data to indicate how much of said memory device needs to be allocated to 
store the data file on Page 12 of the Appeal Brief. However, reading the claims in the 
broadest sense, Hiroshima does meet that limitation in the claims. Hiroshima discloses 
that fields 1 1 0-1 28 make up the header of the packet. The header includes data that 
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indicates how much memory needs to be allocated to store the data file (See Fig. 6, 
122). In other words, it indicates how much of a buffer size it needs to store the file in 
order to process the file (See Hiroshima Fig. 6; col. 8 lines 32-45). 

Appellant argues, "the header each comprise a first field indicating the total 
number of segments in the data file, and the second field indicating the corresponding 
one of the identification codes" on Page 13 of the Appeal Brief. 

In response, the examiner respectfully disagrees with Appellant because Foster 
shows that each segment has a header that identifies the total number of segments 
(col. 7 lines 12-18, unitary header provided for the total data block size) and an 
identification code (STC) (col. 8 lines 60-67, col. 9 lines 1-13, using look up table to 
identify the STC in storage location for playback). The STC code in the header indicates 
the order in the file (col. 7 lines 5-35, col. 9 lines 1-23, STC in header). Notes, as above 
discussion, the headers taught by Foster are NOT generated at the STB, as alleged by 
Appellant but rather the STB recovers the audio PES packets data, video PES packets 
data from the Transport stream 210 according to MPEG-2 Standard, as disclosed (Col. 
5, lines 55-Col. 6. lines 50). 

Appellant argues, "Foster et al., however, does not disclose or suggest 
determining whether all segments of a data file are received... and then storing 
completely received and incompletely received data files in respective portions of a 
memory device" on Page 15 of the Appeal Brief. 
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In response, the Examiner respectfully disagrees with Appellant because Foster 
clearly shows the use of a queuing buffer system to store incompletely received data 
files (col. 4 lines 25-37, col. 6 lines 13-35, queuing buffers for storing incoming data into 
full blocks). The system stores incoming data in the buffer, and when the buffer is filed 
with a completely packet size, the entire packet is written to the mass storage (col. 4 
lines 25-37, col. 6 lines 13-35, 50-60, data blocks of fixed size writing to memory after 
stored in buffer). The buffer clearly meets the limitation of storing incompletely received 
data files and. the mass storage, or HDD, clearly meets the limitation of storing 
completely received data files since the stored blocks of data are recovered at the STB 
from the Transport stream 210, as above discussion. 

Appellant argues, "Foster et al does not teach or suggest the STB determining 
which packets or bytes in packets have not been received" on Page 15 of the Appeal 
Brief 

In response, the Examiner respectively disagrees with Appellant because Foster 
explicitly states that two parallel processes are performed to determine if data files have 
been received (col. 8 lines 15-35). These processes count the amount of data in the 
buffer and compare it to a preferred data size (col. 8 lines 15-20, preferred value of total 
data size is counted). As stated in Foster, the blocks of audio and video data are then 
queued to the buffers forming storage queues until the total data size established by the 
BTI value or count set at 520 is reached" (col. 8 lines 19-21). This process effectively 
determines when data files have been received. When the buffer is filled, the entire data 
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file has been received and is subsequently stored in mass storage. The Examiner 
further indicates that monitoring the progress of storing packets is done by Foster's 
receivjng device using algorithm of Fig. 3 in which the monitoring process is done by 
counting until the full data block size has been accumulated. 

Appellant argues, "Foster et al. does not teach or suggest the STB determining 
which packets or bytes in packets have not been received" and further argues, "Foster 
et al. does not perform monitoring as claimed" on Page 15 of the Appeal Brief. 

In response, Foster explicitly states that "two parallel processes" are performed 
to determine if data files have been received (col. 8 lines 15-35). These processes 
count the amount of data in the buffer and compare it to a preferred data size (col. 8 
lines 15-20, preferred value of total data size is counted). As stated in Foster, the blocks 
of audio and video data are then queued to the buffers forming storage queues until the 
total data size established by the BTI value or count set at 520 is reached" (col. 8 lines 
19-21). This process effectively determines when data files have been received. When 
the buffer is filled, the entire data file has been received and is subsequently stored in 
mass storage. In doing so, the system inherently monitor the receiving data file so to be 
able to determine which data file has not been received, and further to determine if the 
entire data file has been received, as disclosed. 

Appellant argues, "Rieger III does not disclose. ..alerting" on Page 14 of the 
Appeal Brief. 
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In response, Rieger clearly shows that an audio alarm is triggered when data has 
been correctly received (coi. 5 lines 40-50, after capturing transmission, receiver emits 
audio alarm to attract attention to newly saved data). 

Appellant further argues, "Rieger III does not teach header comprising..." on 
Page 14 of the Appeal Brief. 

In response, with regard to limitation "header", this limitation has been discussed 
above in light of the Foster et al reference. As such, One ordinary skill in the art would 
be motivated at the time the invention was made to modify to combine Foster in view of 
the teach of Rieger to emit an audio alarm to notify user that data has been correctly 
received, as suggested by Rieger. 

Claims 13-15, Appellant argues, "Foster et al does not suggest segment codes 
as claimed" on Page 17 of the Appeal Brief. 

In response to appellant's argument that the references fail to show certain 
features of appellant's invention, it is noted that the features upon which appellant relies 
(i.e., segment codes) are not recited in the rejected claim(s). Although the claims are 
interpreted in light of the specification, limitations from the specification are not read into 
the claims. See In re Van Geuns, 988 F.2d 1181,26 USPQ2d 1057 (Fed. Cir. 1993). 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 
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For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 

Joseph G. Ustaris 
AU 2623 



Conferees: 
Chris Kelley 
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